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SELF IMPLEMENTING MULTICAST LEVEL ESCALATION 

15 



20 FIELD OF THE INVENTION 

This invention relates to multicasting on a data network, and more particularly 
to television broadcasting on the Internet 

BACKGROUND OF THE INVENTION 

25 Internet Protocol (IP) multicasts are addressed to a certain range of IP Address 

Numbers. Multicasts are recognized by the numeric address range of the IP number. 
There exist a number of protocols and related methods for distributing IP multicast 
television and radio signals across the Internet In theory, the multicast signals are 
transmitted to the Internet Service Providers (ISPs) so the multicast signals can be 

30 received by the end users. Any transmission in the multicast address range is a 
multicast This is analogous to a range of telephone numbers being assigned for 
* conference calling. 
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Many computers with Internet access are incapable of receiving IP multicasts. 
Even though almost all routers include multicast support, most public networks 
providers (Internet Service Providers (ISPs)) choose not to enable or support IP 
multicasts. The ISPs have been reluctant to implement IP multicast software because 
5 of fears that this will reduce bandwidth and, thereby, reduce billings. Also, due to 
complexity it would seem that the ISP might have a case against implementation 
because it sometimes holds true with computers that increased complexity means 
decreased stability. 

Some solutions have been provided for trying to answer the above concerns. 
10 For example, US Patent No. 6,046,989 to Takahashi discloses a system for multicast 

communication with a plurality of registered users assigned respective target 

addresses and dynamic updating of a multicast connection group. The disadvantages 

of Takahashi is that by cataloging the channels (IP multicast address) the end user is 

not aided in receiving a channel This is comparable to knowing that the Super Bowl 
15 was on channel 2 but not having a TV to receive it Takahashi fails to create a simple 

method for the end user to connect to Internet television progr amm m g 

In another example, US Patent No. 5,982,775 to Brunner discloses a system 

for forwarding multicast frames over an Ethernet bridged network infrastructure. 

Brunner fails to deal with the reception of Internet Broadcasts (IP multicasts) but 
20 rather is attempting to forward die broadcasts across an Ethernet (a network typically 

used to plug computers together in die office). The end user still needs a smart 

appliance to receive them. 

Therefore, there exists a need for providing easy access to IP multicast 

transmissio ns . 

25 

SUMMARY OF THE INVENTION 
A system, method and computer readable medium for allowing multicast 
receiving at a user computer coupled to a subnetwork that is coupled to a public data 
network is provided. The present invention determines if a request for a mulitcast 
30 join has occurred, tests a subnetwork for a first multicasting protocol, if it a request 
for a mulitcast join was determined to have occurred, implements the first 
multicasting protocol, if die result of die test is above a criteria. If the result of die 
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test is below the criteria, the invention tests a subnetwork for a subsequent 
multicasting protocol and implements die subsequent multicasting protocol, if the 
result of the test is above the criteria. The testing of a subnetwork for a subsequent 
multicasting protocol and implementing the subsequent multicasting protocol, is 
5 repeated until the result of the test is above the criteria. 

An object of the present invention is to allow the users of computers to 
receive Internet based television and radio Hke signals. 

The present invention is a method to implement any "open" or proprietary 
multicast standards. Different routing protocols (open or not) are automatically 
10 implemented on a user's computer, thereby making it easy for a user to connect to an 
Internet multicast transmission. 

As will be readily appreciated from the foregoing summary, the invention 
provides a system, method and computer readable medium for allowing multicast 
receiving at a user computer coupled to a subnetwork that is coupled to a public data 
15 network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The preferred embodiment of this invention is discussed in detail below with 
reference to die following drawings. 
20 FIGURE 1 illustrates a block diagram of example subnetwork environments 

that interact with the present invention. 

FIGURE 2 is a block diagram of an example user system formed in 
accordance with the present invention. 

FIGURES 3 and 4 are flow diagrams for performing die process of the present 
25 invention. 

FIGURE 5 is example source code for the process illustrated in FIGURE 4. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

The present invention provides a system, method and computer readable 
30 medium for allowing multicast receiving at a user computer within a subnetwork 
(subnet) that is coupled to a public data network (Internet) or for user systems directly 
connected to the network. FIGURE 1 illustrates example network environments 
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where user/client systems receive multicast signals, such as television or radio. 
Multiple subnets are coupled to the Internet backbone 30. The subnets include 
user/client systems, content provider systems or a combination of the two. For 
example, a first subnet 20 includes an Internet Service Provider (ISP) 34 that allows 
5 multiple user systems 36 and a company's subnet 38, with a server system 40 coupled 
to internal user systems 42, to communicate with other systems over the backbone 30. 
Subnet 22 includes a company's server system 48 coupled to internal user 
systems 50. Other configurations of subnets may be used with the present invention. 
FIGURE 2 illustrates the components of a user/client system 54 formed in 

10 accordance with die present invention. The user/client system 54 includes a 
processor 56 or other device for controlling communication to and from die 
backbone 30, a user interface 58, such as a display, keyboard or other user interface 
device, and a database 60. The database 60 or memory stores a plurality of multicasts 
protocols and software components for directing the processor 56 to perform the 

IS functions of the present invention. The software components include a testing 
component for testing/asking the subnet and its components (routers and user 
systems) about multicast protocol use, and a controlling component for initializing 
one of the stored multicast protocols according to the results of die testing 
component Essentially, die processor 56 performs protocol level escalation. Some 

20 example "open" internet standards stored in the database 60 are Multicast Protocol 
Extensions for Border Gateway Protocol (BGP-4) and Protocol Independent 
Multicast (PIM)-Sparce Mode. The database 60 also stores proprietary multicast 
protocols. The process performed by the software components of the present 
invention are described below with respect to FIGURES 3 and 4. 

25 As shown in FIGURE 3, first, at decision block 80, the user system's 

processor 56 under control from the software components stored in the database 60, 
checks to see if a request to join a multicast has occurred. This is a continual check 
that is simply seeing if the user has selected or there is an automatic selection of a 
web address of a site that sends a multicast signal. If there is a request to join a 

30 multicast, at block 82, the testing component test the subnet and its components for a 
first one of die locally stored multicasting protocols. Next, at decision block 84, the 
processor 56 analyzes the results of the test according to the type of response received 
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from the subnet If a message is received from the subnet or a component thereof that 
the multicast protocol tested for can or is being used and the processor 56 determines 
that the received message meets a preset criteria, at block 86, the processor 56 
initializes the tested-for multicast protocol and reception of the multicast signal 
5 occurs. If either a message is not received from the subnet or a component thereof 
that the multicast protocol tested for can or is being used, or the processor 56 
determines that the received message does not meet the criteria, at block 88, the 
testing component tests the subnet for a subsequent one of the locally stored 
multicasting protocols. Then, at decision block 90, if a message is received from the 
10 subnet or a component thereof, that die subsequent multicast protocol tested for can 
or is being used and the processor 56 determines that die received message meets the 
criteria, at block 92, the processor 56 initializes the tested-for subsequent multicast 
protocol and multicasting occurs. If, at decision block 90, either a message is not 
received from the subnet or a component thereof, that the subsequent multicast 
15 protocol tested for can or is being used, or die processor 56 determines that the 
received message does not meet the criteria, the process returns to block 88 until an 
acceptable multicast protocol is found. If an acceptable multicast protocol is not 
found, the multicast protocol with the best results, when compared to the criteria, is 
used, or a default multicast protocol is used. 
20 As shown in the example of FIGURE 4, the present invention watches 

Internet transmissions for multicast joins. Joins are requests to become part of the 
group that are receiving the multicast signal. When die present invention sees a 
multicast join command, it interrupts the program flow to test for multicasting 
protocols available on the network. In this example the PIM Sparce Mode is tested 
25 for by pinging the "All PIM Routers" IP address. If the current level of protocol fails 
(there is no response to die query for PIM routers) the next level of protocol is 
enabled (BGP-4). By self implementing different routing protocols (open or not) the 
present invention, die user need not be concerned with the protocols being used. The 
user can concentrate on the viewing the received multicast data and not get mired 
30 down in manual programming of different protocols. 

FIGURE 5 shows a simple source code construction for die process illustrated 
in FIGURE 4. 
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While the preferred embodiment of the invention has been illustrated and 
described, it will be appreciated that various changes can be made without departing 
from the spirit and scope of the invention. 
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CLAIMS 

The embodiments of die invention in which an exclusive pro pert y or privilege is 
claimed are defined as follows: 
5 1. A method for receiving over a public data network a multicast signal 

at a user system coupled to the public data network, the method comprising: 
determining if a request to receive the mulitcast signal has occurred; 
testing a subnetwork for a first multicasting protocol, if a request to receive 
the mulitcast signal was determined to have occurred; 
10 implementing the first multicasting protocol, if the result of die test is above a 

criteria; 

testing the subnetwork for a subsequent multicasting protocol, if the result of 
die test is below the criteria; 

implementing the subsequent multicasting protocol, if the result of die test is 
15 above the criteria; 

repeating testing a subnetwork for a subsequent multicasting protocol and 
implementing the subsequent multicasting protocol, until the result of die test is 
above die criteria. 

20 2. Hie method of Claim 1, wherein the testing tests a subnetwork that 

does not include the user system. 

3. The method of Claim 1, wherein if the testing fails to produce a result 
above the criteria, a default multicast protocol is implemented. 

25 

4. An apparatus for receiving at a public data network a multicast singal 
at a user system (54) coupled to the public data network, the apparatus comprising: 

memory (60) for storing a plurality of multicast protocols; 
a user interface (58) for allowing a user to request a multicast signal from a 
30 source coupled to the public data network; and . 

a processor (56) for communicating with the public data network, the 
processor comprising: 
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a determining component for determining if a request for a mulitcast 
join has occurred; 

a testing component for testing a subnetwork for a first multicasting 
protocol, if it a request for a mulitcast join was determined to have occurred; and 
5 a mulitcast component for implementing the first multicasting 

protocol, if die result of the test is above a criteria, 

wherein the testing component tests the subnetwork for a subsequent 
multicasting protocol, if the result of the test is below the criteria, the mulitcast 
component implements the subsequent multicasting protocol, if the result of die test 
10 is above a criteria and die processor repeats testing a subnetwork for a subsequent 
multicasting protocol and implementing the subsequent multicasting protocol, until 
the result of die test is above the criteria. 

5. The apparatus of Claim 4, wherein the testing component tests a 
15 subnetwork that does not include die user system. 

6. The apparatus of Claim 4, wherein if the testing component fails to 
produce a result above the criteria, a default multicast protocol is implemented 
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OS SUBfSIMPLE, Sen) 

10 IF Ipmulticast REM (Has (here been a request for a 

REM Multicast Join?) 
ELSE RETURN REM Exit 
20 CALL PmGfAUPimRouterSyExitStatyPingError) 
SOlFExiiStat 

CALL INITPBffPIMErr) REM (If ping successful Initialize 

REM PMRFWCXXXXX) 

RETURN 
40 CALL INITMBGPfBGPErr) 
CALL INITPIM (PBfErr) 
RETURN 
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